...  【預設機制讓 MPL-2.0 程式碼可以同時適用 GPL 來授權散布】 MPL 系列條款由 Mozilla 基金會 (Mozilla Foundation) 所制定，其規定 MPL 的衍生檔案仍然必須適用 MPL 繼續授權，因此同樣是一份具有授權拘束性的條款，與 GPL 原則上並無法結合相容在同一個專案中。不過為了讓 MPL 可以與 GPL、LGPL 等條款相容，Mozilla 基金會在授權機制上做了調整，弱化 ...

...  針對這樣的運用方式，GPL-2.0、GPL-3.0、Apache-2.0、MPL-2.0 與 EPL-1.0 等授權條款，均有明確的文字，表示使用者可以透過收取費用的方式來提供額外的保證或擔保（註三）。而這種保證或擔保費用的收取，更是自由開源軟體的客製化承包商，得以生財牟利的彈性化商業應用模式。 值得注意的是，此類保證或擔保的承諾，是由特定使用者所自行提供，因此未來若是保證或擔保事由真的發生的話，也必須由這位特定的使用者自己來承擔保證或擔保責任，原自由開源軟體的授權人或其他的使用者，並不會連帶被課予這樣的保證或擔保責任。在一些授權條款中，有著明確的文字來闡明這樣的原則。所以若是因為某特定使用者額外提供的保證或擔保承諾，而使得授權人或其他使用者遭致損失或必須負擔額外責任的話，這位特定的使用者就必須協助授權人或其他使用者，來免於負擔這些額外的責任，而在授權人或其他使用者因此受有損失的情況下，這位特定使用者還必須要加以賠償這些無辜受殃者所遭遇的損失。 ...

... sublicense 機制的條款，以在日後得以直接依條款規劃的機制處理上述問題。   【sublicense 於自由開源軟體領域的應用方式與差異】   右列幾款常見的自由開源授權條款，如：Apache-2.0、MIT、CPL-1.0、EPL-1.0、CDDL-1.0，以及 MPL-2.0（散布可執行檔格式時，註三），均有著明確容許 sublicense 的文字。所以如果使用者參與開發的是以這些授權方式進行共工的專案，授權規劃上，便可以在改作或是再行散布時，適當標註前專案與後專案之間的歷史關係，以及原創作人與創作團隊的顯名聲明之後，將後續專案轉以自己的名義向外授權。舉例來說，如果原來的自由開源軟體「AAA ...